As is known in the art, there are a variety of systems for authenticating a user to a computer and/or computer network. For example, to log on to a computer, a user typically types in a password. However, as is well known in the art, a password-only system provides a limited level of security.
Other known authentication systems require two factors of identification. One such system is the RSA SECURID system by RSA Security Inc., of Bedford, Mass. In general, this system requires a user to input an alpha-numeric Personal Identification Number (PIN) and data from a device in form of an authentication token in possession of the user. A server verifies the user PIN and the security data from the token, which is known by the server. The RSA SECURID system is generally described in U.S. Pat. No. 4,720,860 to Weiss, which is incorporated herein by reference.
Authentication tokens, such as the RSA SECURID token, are becoming increasingly common for authenticating a user to a server over an insecure channel. The benefits of authentication tokens over the use of standard passwords are numerous, relating primarily to the reduced risks of impersonation attacks. Impersonation attacks refer to an unauthorized person attempting authentication to a secure server, and thereby access a corporate network, for example.
Typically, the authentication token shares some information with an authentication server, such as an RSA Security ACE server, where this information is typically not known to other entities, and where this information allows the generation and verification of at least parts of some authentication string. This authentication string commonly also includes, or is a function of, some information that is memorized by the owner of the token and also stored on the server. The authentication may be interactive, e.g., a challenge-response format, or non-interactive, e.g., no information is sent from the server to the user/token in order to complete the generation of the authentication string.
Currently, the information that constitutes the authentication attempt is sent over some potentially insecure communication link, such as a wireless or wired network. In one common scenario, the user in possession of the authentication token wishes to access some resource controlled by the server. The server can be assumed to be secure against attacks so that it can also be assumed that the secret information stored by the server cannot be compromised and used for purposes of impersonation of the user in question. The above-mentioned resource may be, for example, a database, an E-mail account, a storage unit, or processing ability. It can be assumed that this resource does not need to store any information useful for generating authentication strings, unless the resource coincides with the server performing the verification.
While such systems are effective for authentication of users in conjunction with a remote authentication server, the current system may not be effective when the authentication server is not available or impractical if the resource to which access is wanted is a computer that the token owner is in possession of. Under such circumstances, it would be beneficial if the computer could verify the authentication code without interaction with the remote authentication server. However, if the computer is lost or stolen, or otherwise controlled by an intruder, then this intruder could potentially obtain verification information and use this to attempt to impersonate the user (i.e., the token) to the remote authentication server. Thus, while some information may be stored on the computer in order to allow for authentication of token outputs, it should not introduce unacceptable security vulnerabilities.
It would, therefore, be desirable to overcome the aforesaid and other disadvantages.